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Abstract  -  For  the  testing  of  control  and  communications 
algorithms  in  cooperative  behavior,  a  fleet  of  autonomous 
underwater  vehicles  (AUVs)  is  under  development  by  the 
University  of  Idaho.  This  paper  discusses  one  piece  of  the  puzzle 
in  this  fleet:  the  communications  module  to  manage  multiple 
agents.  The  communications  system  provides  multiple  modes  of 
operation.  Different  communications  mediums  to  and  from  the 
vehicle  support  these  modes  of  operation.  The  tools  supplied  by 
the  different  modes  of  operation  assist  the  researchers  in 
developing  communications,  control  algorithms,  and  valuable 
hardware  systems. 

I.  INTRODUCTION 

The  modem  battlefield  is  evolving  into  a  profusion  of 
machines.  Technology  replaces  manpower  to  perform 
dangerous  tasks  in  an  effort  to  reduce  wartime  casualties.  The 
United  States  Navy,  in  the  interest  of  using  technology  in  the 
form  of  autonomous  underwater  vehicles  (AUVs),  desires 
vehicles  for  mine  countermeasures  (MCMs)  and  the  mapping 
of  landing  zones.  A  single  AUV  has  proven  to  be  successful  in 
performing  these  operations  [1].  The  University  of  Idaho  is 
performing  research  and  development  of  a  fleet  of  test 
platforms  of  which  the  prototype  is  shown  in  Fig.  1.  These  test 
platforms  are  used  by  the  researchers  to  explore 
communications  and  control  algorithms  for  a  fleet  of  AUVs 
maneuvering  in  formation  cooperatively  searching  for  mines 
and  mapping  landing  zones.  The  benefits  of  using  multiple 
AUVs  include  increased  reliability  through  redundancy, 
increased  area  coverage  in  a  shorter  amount  of  time,  and  higher 
quality  of  measurements  through  overlapping  coverage  [2]. 

The  primary  motivation  in  the  construction  of  a  fleet  of 
autonomous  underwater  vehicles  is  the  development  of 
algorithms.  The  primary  vision  of  the  research  platform  is  to 
minimize  the  algorithm  development  time.  The  mission  cycle, 
shown  in  Fig.  2,  reduces  development  time  by  providing  an 
organized  methodology  to  algorithm  development.  The 
mission  cycle  starts  with  an  idea  or  concept.  The  researchers 
simulate  their  ideas  for  algorithms  in  a  computer  environment. 
From  a  successful  simulation  they  create  mission  files  to 
upload  onto  the  vehicles.  The  vehicles  are  put  into  the  water  to 
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Fig.  1.  The  University  of  Idaho  prototype  vehicle. 


Fig.  2.  The  vision  of  the  mission  cycle. 


run  the  programmed  missions.  While  running  a  mission  the 
vehicles  collect  data  and  store  it  in  internal  memory.  When  the 
mission  is  concluded  the  data  is  retrieved  and  analyzed.  The 
analyzed  data  provides  measures  to  assess  performance  and 
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insights  into  ways  improve  algorithms  for  another  mission 
cycle. 

This  paper  focuses  on  the  vehicle’s  communications 
module  and  its  external  communications  channels  as  well  as 
the  proprietary  fleet  management  software  used  in  surface 
operations  for  the  test  platform.  The  communications  module 
provides  three  modes  of  operation  supported  by  three 
communication  mediums  external  to  the  vehicle  and  one 
internal.  The  internal  channel  leads  to  a  distributed  network 
supported  by  Ethernet  using  TCP/IP  and  UDP  protocols.  The 
distributed  control  network  passes  messages  between 
microprocessor  nodes  within  the  vehicle.  As  this  is  the  topic  of 
another  paper  [3],  little  else  will  be  said  about  the  internal 
network. 

The  external  channels  provide  three  methods  for 
communicating  with  the  world  outside  the  vehicle.  One 
method,  referred  to  as  the  real-time  communications  channel, 
provides  real-time  fleet  management  of  the  vehicles  while  on 
the  surface  and  between  autonomous  missions.  Another 
method  configures  the  vehicles  prior  to  running  an  autonomous 
mission  and  downloads  the  data  gathered  after  an  autonomous 
mission  is  complete.  The  user  connects  through  web  pages, 
served  by  the  vehicle  itself,  to  configure  systems  and  download 
data.  The  final  method  communicates  through  an  acoustic 
modem.  The  modem  serves  two  purposes:  it  acts  as  a  sensor 
for  navigation  by  calculating  position  based  off  of  Long 
BaseLine  (LBL)  active  navigation  and  it  provides  the  medium 
for  communications  between  vehicles  operating  in  autonomous 
mission  mode. 

II.  REAL-TIME  COMMUNICATIONS 

Between  missions  the  user  needs  the  ability  to  control  the 
vehicle  into  a  position  away  from  obstacles.  The  real-time 
communications  link  and  proprietary  control  software  provides 
this  function,  using  the  keyboard,  mouse,  or  joystick  for  user 
input.  Other  functions  include  the  real-time  display  of 
telemetry  and  surface  position  information,  the  ability  to  start 
and  abort  missions,  and  the  data  display  and  control  of  up  to 
eight  AUVs. 

A.  Hardware  (Fig.  3.) 

A  pair  of  model  9XStream  [4]  wireless  radio  modems 
made  by  MaxStream,  provides  the  wireless  communications 
link.  The  9XStream  model  operates  at  a  frequency  of  900MHz 
and  transmits  data  at  9600  baud.  A  Yagi  high-gain,  directional 
antenna  on  the  base  station  provides  a  maximum  range  of  32 
kilometers,  line-of-sight  and  in  optimum  conditions.  In  some 
cases  the  radio  signal  is  capable  of  penetrating  the  surface  of 
the  water  to  a  depth  of  0.5  meters  that  proved  invaluable  during 
the  initial  design  phase  of  the  vehicle. 

On  the  vehicle,  a  RCM3000  [5]  microcontroller,  made  by 
Rabbit  Semiconductor,  provides  the  link  from  devices  internal 
to  the  vehicle  to  devices  external.  The  RCM3000  (RCM 
stands  for  Rabbit  Core  Module)  operates  at  29.4  MHz,  has  one 
megabyte  of  memory  evenly  divided  between  flash  and 
SRAM,  and  makes  available  an  Ethernet  port  and  other  pins 


Fig.  3.  The  real-time  communications  hardware. 

for  serial  communications.  As  mentioned  earlier,  the  Ethernet 
port  provides  connectivity  to  the  internal  distributed  network. 

A  laptop  computer,  running  the  Windows  XP  operating 
system  (OS),  a  joystick,  and  a  global  positioning  system  (GPS) 
receiver  complete  the  hardware  and  act  as  the  base  station. 
The  joystick  is  an  optional  tool  because  all  joystick  controls 
have  a  related  keyboard  command  (the  joystick  is  favored  over 
keyboard  control  for  its  obvious  ease  of  use).  A  laptop,  as 
opposed  to  a  desktop  computer,  provides  mobility  and  over 
two  hours  of  battery  operation  in  case  a  power  source  becomes 
unavailable.  This  seemingly  minor  feature  has  the  benefit  of 
allowing  users  to  locate  and  recover  vehicles  when  external 
power  is  not  available. 

B.  Software 

The  real-time  communications  software  on  the  vehicle 
conveys  messages  between  devices  on  the  internal  distributed 
network  and  the  radio  modem.  Every  500  milliseconds  the 
data  from  the  sensors,  along  with  mission  state  and  local  x-  and 
y-coordinates,  gets  formed  into  packet.  This  packet  is  tagged 
with  a  message  identifier  and  vehicle  identification  number  and 
transmitted  via  the  radio  modem.  There  are  currently  three 
types  of  messages  received  by  the  radio  modem  from  the 
laptop.  The  first  kind  of  message  controls  fin  positions  and 
motor  speed.  These  messages  are  sent  directly  to  the 
motor/servo  controller.  The  other  two  messages  are  the  start 
and  abort  mission  messages,  which  are  sent  to  the  autonomous 
vehicle  controller,  or  the  ‘brain’  of  the  vehicle.  The  start 
mission  message  contains  a  number  identifying  the  number  of 
the  mission  to  start.  How  these  different  missions  get  into  the 
vehicle  controller  is  mentioned  later.  Abort  mission  messages 
obviously  are  passed  to  the  controller  to  tell  it  to  stop  the 
currently  running  mission,  which  is  useful  if  the  user  notices 
the  vehicle  behaving  inappropriately  and  the  radio  modem  is 
still  in  contact  with  the  vehicle. 

The  software  Graphical  User  Interface  (GUI)  is  a 
Windows  OS  executable.  The  inputs  to  the  program  come 
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Fig.  4.  Screenshot  of  AUV  Control  Panel  software. 


from  the  mouse,  keyboard,  joystick,  and  the  radio  modem 
attached  via  the  Universal  Serial  Bus  (USB).  The  outputs  are 
the  display  and  the  control  packets  that  are  sent  out  the  radio 
modem. 

C.  Features 

Fig.  4  is  a  sample  screenshot  of  the  AUV  Control  Panel 
while  in  action.  The  incoming  telemetry  data  for  two  vehicles 
are  displayed  with  vehicle  #3  having  the  focus  for  control 
commands.  The  thicker  border  around  the  data  indicates  the 
focus  for  control  commands.  The  features  and  their  benefits 
for  the  AUV  Control  Panel  are  now  enumerated  using  Fig.  4, 
as  an  example. 

1)  Real-time  display  of  telemetry  data 

When  the  vehicles  are  active  and  on  the  surface,  they 
transmit  specific  data  indicating  position,  orientation  and 
internal  telemetry.  If  the  vehicle  and  the  GUI  are  configured 
for  the  same  network  (256  networks  available),  the  same 
hopping  channel  (seven  channels  available),  and  within  range 


of  the  antenna,  this  data  is  displayed  on  the  screen. 
Theoretically,  the  GUI  can  display  data  for  14336  vehicles  (7 
hopping  channels  x  256  networks  x  8  vehicles  per  network). 
This  is  in  theory,  but  the  reality  of  it  is  that  there  are  limitations 
in  the  radio  frequency  channel.  Fig.  4,  shows  the  reception  of 
data  from  vehicles  #1  and  #3  that  are  on  network  zero  using 
hopping  channel  one.  The  telemetry  data  includes: 

•  GPS  information  -  latitude,  longitude,  heading, 
velocity,  and  Horizontal  Position  Error  (HPE). 

•  Depth. 

•  Compass  information  -  heading,  dip,  pitch,  and  roll. 

•  Yaw  rate. 

•  Accelerometer  information  -  pitch  and  roll  (used  in 
gyrocompass  graphic). 

•  Velocity  from  a  flow  sensor. 

•  Environmental  information  -  battery  voltage,  current, 
and  state  of  charge;  temperature  inside  the  vehicle. 

•  Mission  mode  state  -  out,  in,  or  initializing. 
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•  Local  x-coordinate  and  y-coordinate  in  meters  as 
determined  by  LBL. 

•  Gyrocompass  graphic  -  visual  feedback  of  vehicle 
heading  (from  compass),  pitch,  and  roll  (from 
accelerometers). 

2)  Real-time  vehicle  control 

Researchers  need  the  ability  to  control  the  vehicles  during 
launch  of  and  recovery  from  missions.  To  this  end,  the  Control 
Panel  sends  control  messages,  via  the  real-time  wireless 
communications,  to  the  vehicles.  Fig.  4,  shows  telemetry  data 
arriving  from  two  different  vehicles.  Either  of  these  vehicles 
or  both  can  be  controlled  with  joystick  or  keyboard  commands 
when  they  have  the  focus.  The  user  sets  the  focus  to  individual 
vehicles  to  control  them  into  the  starting  point  for  missions  and 
selects  multiple  vehicles  when  the  user  starts  multiple  vehicles  Fig.  5  Master  (left)  and  slave  (right)  controller 

on  the  same  mission  or  controls  the  vehicles  concurrently.  hardware.  The  master  controls  the  wireless  Ethernet. 


3)  Commanded  feedback 

Commanded  rudder  and  planes  positions  along  with 
commanded  engine  power  (represented  as  a  percentage)  are 
displayed  in  the  upper  left  corner  of  the  screen.  The  antenna 
symbol  in  the  extreme  upper  left  comer  indicates  that  the  radio 
is  actively  sending  and  receiving  data.  A  digital  clock  of  the 
current  system  time  assists  in  tracking  mission  start  times. 
Specifying  a  mission  number  in  the  scroll  box  (Fig.  4)  and 
selecting  the  ‘Start  Mission’  button  on  the  screen  will  send  the 
message  to  start  the  mission.  Pulling  the  trigger  on  the  joystick 
sends  an  abort  mission  command.  All  previously  mentioned 
controls  have  equivalent  keyboard  commands  and  affect  the 
selected  vehicle(s)  equally. 

4)  Top-side  tracking 

Every  vehicle  has  the  capability  of  reporting  its  GPS  data 
when  its  GPS  receiver  is  unobstructed  from  the  satellites.  This 
GPS  data,  along  with  the  GPS  data  for  the  base  station,  helps  to 
locate  the  position(s)  of  the  vehicle(s)  relative  to  the  base 
station.  As  of  the  writing  of  this  paper,  this  feature  is  still 
under  development  and  the  image  in  the  upper  left  corner  is 
merely  a  placeholder  for  where  the  user  will  eventually  see  the 
GPS  information  displayed.  The  ability  to  locate  the  vehicles 
at  mission  end  assists  in  their  recovery. 

III.  MISSION  CONFIGURATION  AND  DATA 
DOWNLOAD 

With  the  vehicle  in  the  laboratory  or  on  the  dock  in  the 
staging  area,  researchers  need  the  ability  to  configure  the 
vehicle  and  download  its  mission  data  log.  A  wireless  Ethernet 
connection  with  web  pages  served  up  by  the  vehicle  itself 
provides  this  function.  Using  a  wireless  form  of  access  to  the 
vehicle’s  data  reduces  wear  and  tear  on  the  seals  that  keep  the 
vehicle  watertight.  The  short  range  of  wireless  Ethernet 
doesn’t  permit  real-time,  long-range  control  of  the  vehicles  but 
the  high-speed  connection  permits  fast  data  download  while 
the  vehicle  is  close. 


A.  Hardware  (Fig.  5.) 

A  Linksys  model  WCF12  [6]  wireless  CompactFlash  card 
provides  the  wireless  Ethernet  link.  The  CompactFlash  plugs 
into  a  Type  1  slot  and  makes  available  a  link  using  the  802. 1  lb 
standard,  operating  at  2.4GHz. 

On  the  vehicle,  a  Rabbit  Semiconductor  RCM3100  [7] 
microcontroller  provides  the  link  between  a  slave 
microcontroller  (the  same  microcontroller  used  for  the 
previously  described  real-time  communications)  and  the 
wireless  CompactFlash  card.  The  RCM3100  Rabbit  Core 
Module  operates  at  29.4  MHz,  has  one  megabyte  of  memory 
evenly  divided  between  flash  and  SRAM,  and  has  pins  for 
connecting  to  a  slave  device  and  an  external  memory  device. 
The  wireless  CompactFlash  card  gets  accessed  like  an  external 
memory  device. 

Any  properly  configured  computer  with  a  wireless 
Ethernet  card  can  acquire  the  ad  hoc  connection.  The  same 
laptop  providing  real-time  communications  accesses  the 
wireless  Ethernet. 

B.  Software 

A  special  software  packet  driver  library  for  controlling  the 
pins  of  the  CompactFlash  card  is  available  from  Rabbit 
Semiconductor.  This  driver  provides  the  necessary  functions 
for  using  most  any  TCP/IP  communications  protocol.  The 
wireless  Ethernet  uses  Hypertext  Transfer  Protocol  (HTTP)  for 
serving  up  web  pages  and  File  Transfer  Protocol  (FTP)  for  data 
download.  Most  of  the  web  pages  are  created  statically 
(HTML  files  are  created  before  compile  time)  and  compiled 
into  the  flash  memory.  Other  web  pages  are  created 
dynamically  at  run-time,  using  current  data  from  inside  the 
vehicle.  For  example,  the  different  runs  that  are  stored  in  the 
data  log  are  displayed  in  a  table  format  created  at  run-time  so 
that  the  user  can  select  a  link  to  choose  a  log  for  FTP 
download. 

As  mentioned  before,  any  properly  configured  computer 
can  link  to  the  wireless  network  card  and  access  information 
from  a  vehicle.  The  user  needs  only  to  start  a  web  browser  and 
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Fig.  6.  Screenshot  of  home  page  for  vehicle  #1. 


link  to  the  static  IP  address  of  the  vehicle.  Once  on  the  home 
page,  the  user  can  click  on  links  in  navigation  bar  (left  side  of 
Fig  6.)  to  access  other  information  stored  on  the  vehicle.  No 
special  software  is  required  on  the  PC  to  access  this 
information. 

C.  Features 

Figs.  6,7,  are  example  screenshots  of  actual  web  pages  that 
are  served  by  a  vehicle.  Fig.  6,  is  the  home  page  while  Fig.7, 
is  an  example  of  the  data  download  page.  The  features  and 
benefits  of  the  varying  web  pages  are  now  enumerated  using 
the  Figs.  6,7,  as  reference. 

1)  Navigation  Bar 

The  navigation  bar  is  available  in  the  left  column  of  every 
page  and  makes  available  links  to  the  different  ‘departments’ 
on  the  vehicle.  A  ‘department’  defines  an  area  of  the  vehicle 
where  information  (configuration  or  status)  resides.  For 
example,  at  the  ‘department  Science  Station’  link  resides  the 


status  for  the  depth  sensor  and  the  ability  to  calibrate  the  depth 
sensor. 

A  set  of  indicator  lights  shows  the  status  of  the  slave,  the 
radio  modem,  and  the  acoustic  modem.  Clicking  the  reset 
button  on  the  screen  does  a  power  off  reset  of  the  slave 
communications.  This  feature  proved  invaluable  during 
development  when  a  coding  error  for  the  internal  network 
occasionally  caused  the  slave  processor  to  stop  working.  The 
last  bit  of  information  on  the  navigation  bar  is  the  serial 
number  for  the  vehicle.  This  value  is  simply  the  Media  Access 
Control  (MAC)  address  for  the  wireless  Ethernet  card,  which  is 
the  unique  48-bit  address,  assigned  to  all  Ethernet  devices. 

2)  Home  Page 

The  home  page  identifies  the  project  by  displaying  a 
picture  of  the  vehicle.  The  home  page  also  displays  the  current 
communications  configuration.  As  mentioned  in  the  real-time 
communications  section,  the  vehicle  number,  the  network,  and 
the  address  are  all  used  to  identify  this  vehicle  to  the  AUV 
Control  Panel.  The  vehicle  number  is  also  used  to  identify  this 
vehicle  on  the  acoustics  network  (described  later). 
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Fig.  7.  Screenshot  of  data  download  page. 


3)  The  Captain’s  Chair  Link 

The  link  to  the  ‘Captain’s  Chair’  takes  the  user  to  another 
page  for  mission  upload,  data  download,  or  erasing  the 
memory  in  the  data  log.  To  erase  the  memory,  the  reset  button 
on  the  web  page  is  clicked,  while  mission  upload  and  data 
download  requires  following  the  links. 

On  the  mission  upload  page  the  user  can  select  a  file  from 
the  computer’s  file  system  and  upload  it  into  the  vehicle’s 
memory.  Current  versions  of  the  controller  use  a  hard-coded 
parameter  file  on  the  AUV  for  missions  but  future  releases  of 
the  vehicle  will  use  this  mission  file  for  its  parameters.  Recall 
the  mission  number  mentioned  in  the  real-time 
communications  section;  this  number  (which  again  is  currently 
hard  coded)  will  eventually  be  tagged  to  the  filename.  This 
number  also  identifies  the  mission  in  the  data  log  (Fig.  7). 

From  the  data  download  link  the  user  can  download  the 
data  captured  during  a  mission.  The  data  download  web  page 
(Fig.  7)  lists  the  run  number,  the  mission  number,  the  size  of 
the  data  file  in  blocks  (128  bytes  per  block),  and  the  GPS  time 
at  the  start  of  the  mission.  Clicking  the  mouse  pointer  on  the 


link  represented  by  the  run  number  will  start  an  FTP  download 
of  the  data  for  that  run. 

4)  Science  Station  Link 

The  ‘Science  Station’  calibrates  some  of  the  sensor 
devices.  The  depth  sensor  (pressure  guage)  is  reset  to  zero 
when  the  vehicle  is  floating  on  the  surface.  Also,  the  pitch 
sensor  is  reset  to  zero  when  the  vehicle  is  leveled  with  a  level. 

5)  Communications  Link 

The  communications  web  page  provides  links  for  entering 
buoy  positions  used  for  navigation,  and  for  configuring  the 
radio  and  acoustic  modems.  The  vehicle  uses  the  buoy 
positions  for  LBL  active  navigation  (described  later). 
Configuration  values  for  the  radio  modem  that  are  available  to 
be  set  through  the  web  page  are  the  same  ones  displayed  on  the 
home  page.  In  the  current  version  of  the  software  the  acoustic 
modem  parameters  and  most  of  the  radio  modem  parameters 
are  hard-coded  in  the  firmware,  whereas  future  versions  will 
allow  the  parameters  to  be  set  through  this  web  page. 
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Fig.  8.  The  WHOI  acoustic  micromodem  for 
communication  and  navigation. 

6)  Engine  Room 

Early  in  development,  the  designer’s  needed  the  ability  to 
change  the  fin  trim  settings  in  real-time  during  vehicle  tests. 
To  help  the  vehicle  maintain  a  correct  course,  the  fin  positions 
are  zeroed  to  compensate  for  defects  in  manufacturing. 
Another  value  that  can  be  set  in  the  ‘Engine  Room’  is  the 
control  surface  coupling  coefficient,  which  is  used  to  reduce 
rolling  in  the  turns. 

IV.  UNDERWATER  COMMUNICATIONS  AND 
NAVIGATION 

The  emphasis  of  this  research  is  cooperative  behavior  in 
control  and  communications  algorithms.  The  previously 
mentioned  mission  files  define  the  control  algorithms. 
Communications  algorithms  define  how  the  vehicles  cooperate 
in  the  low  bandwidth  environment  of  the  underwater  acoustic 
channel.  The  final  piece  to  the  puzzle  defines  how  the  vehicle 
uses  LBL  active  underwater  navigation. 


process  navigation  messages.  The  timing  for  these  two  tasks  is 
hard-coded  into  the  firmware,  but  in  future  revisions  it  will  be 
changed  through  a  web  page. 

1)  Acoustic  communications 

To  begin  transmission  of  a  communications  message  every 
vehicle  sends  out  a  network  cycle  initialization  packet.  A 
notification  message  is  sent  from  the  modem  to  the  host  of 
every  vehicle  that  receives  the  message.  It  is  also  echoed  back 
to  the  sender  of  the  message.  Among  other  parameters,  the 
message  contains  the  source  and  the  destination  addresses  and 
a  command  parameter  for  identifying  broadcast  messages.  The 
reception  of  this  message  signals  the  host  into  transmit  or 
receive  mode  dependent  on  the  aforementioned  parameters. 

If  the  host  is  identified  as  the  source  of  the  message,  then  a 
request  for  data  to  transmit  is  sent  to  the  controller  node  via  the 
internal  network.  When  the  data  to  be  transmitted  arrives  from 
the  controller  processor,  it  is  immediately  sent  to  the  modem. 

On  the  other  hand,  if  the  command  parameter  identifies 
the  message  as  a  broadcast  and  the  host  is  not  the  source  or  if 
the  host  is  the  destination  for  the  message,  then  the  host  is  put 
into  receive  mode.  While  in  receive  mode,  the  host  accepts 
and  relays  to  the  controller  node  the  next  message  received. 
After  receiving  a  message  or  after  a  timeout,  the  host  is  taken 
out  of  receive  mode  until  the  next  cycle  initialization  packet 
reception. 

2)  Acoustic  navigation 

The  acoustic  navigation  is  performed  using  Long 
BaseLine  (LBL)  active  navigation  pings.  At  intervals 
determined  by  the  firmware,  the  host  sends  an  active 
navigation  ping  message  to  the  modem.  The  modem  then 
pings  the  buoys.  The  response  message  contains  parameters 
identifying  time-of- flight  information  from  each  buoy.  Time- 
of-flight  along  with  information  about  the  buoy  positions  is  all 
that  is  needed  to  determine  the  vehicle’s  position  in  a  local 
coordinate  system  [10].  This  information  is  sent  to  the 
controller  for  navigation  purposes. 


A.  Hardware 

A  Wood’s  Hole  Oceanographic  Institute  (WHOI)  acoustic 
Micro-Modem  [8]  (Fig.  8)  and  an  omni-directional  ceramic 
transducer  are  used  for  communicating  acoustically 
underwater.  The  WHOI  acoustic  modem  provides  for  both 
communications  and  navigation  underwater  [9].  To  navigate, 
the  vehicle  calculates  its  position  relative  to  the  known  location 
of  surface  buoys.  The  same  microcontroller  that  runs  the  real¬ 
time  communications  also  operates  the  acoustic  modem. 

B.  Software 

The  WHOI  Micro-Modem  uses  a  command  set  that 
follows  the  National  Marine  Electronics  Association  (NMEA) 
0183  Standard  for  interfacing  marine  electronics  [8].  This 
standard  defines  messages  as  sentences  that  begin  with  ‘$’  and 
five  characters  and  has  comma-separated  parameters.  These 
messages  are  sent  from  and  read  by  the  firmware  on  the  slave 
microcontroller  (referred  to  as  the  host).  The  host  must 
perform  two  tasks:  relay  communications  messages  and 


V.  RESULTS 

From  the  vehicle’s  first  test  at  the  University  of  Idaho’s 
swimming  pool  in  May  of  2005,  the  communications  module 
has  helped  the  developers  to  design  algorithms  needed  for 
autonomous  control.  The  joystick  interface  gave  researchers 
the  ability  to  quickly  design  a  dive  routine,  vector  control,  and 
an  optimized  surface  operation  through  squat  control.  The 
human-in -the-loop  joystick  actions  were  replaced  by 
autonomous  controls  that  were  programmed  as  missions.  This 
was  how  the  autonomous  controls  were  fine-tuned. 

Throughout  development  and  hundreds  of  missions,  new 
features  have  been  added  to  the  communications  module  to  aid 
developers.  Originally  there  was  just  the  real-time  control 
interface  with  joystick  control  and  telemetry  data  for  one 
vehicle.  The  wireless  control  required  a  communications 
configuration  web  page  for  the  radio  modem  on  the  vehicle. 
Then  there  was  a  need  to  save  the  telemetry  data  to  a  file  for 
post  analysis  while  the  data-logging  feature  of  the  vehicle  was 
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still  under  development.  The  next  thing  added  was  a  web  page 
for  trim  settings  and  coupling  coefficient  to  improve  control 
performance.  After  that  came  the  need  to  zero  certain  sensors, 
improving  the  accuracy  of  sensor  readings.  At  the  end  of 
Summer  2005,  the  catch  phrase  was  ‘dockside  downloading.’ 
This  feature  was  added  to  speed  development  while  reducing 
wear-and-tear  on  the  watertight  seals.  The  most  recent 
addition  is  multiple  vehicle  control  and  telemetry  data. 

The  communications  module  has  proven  valuable 
throughout  multiple  tests.  The  vehicle  has  survived  over  a 
dozen  pool  tests,  a  test  in  a  local  flooded  clay  pit,  and  six  tests 
in  the  waters  of  Lake  Pend  Oreille,  Idaho.  The  most  recent  test 
took  the  vehicle  to  the  Acoustical  Research  Detachment  of  the 
Naval  Surface  Warfare  Center,  Carderock  Division  (ARD- 
NSWCCD)  in  Bayview,  Idaho.  It  was  programmed  to  navigate 
a  path  while  broadcasting  position  information.  This  data  was 
captured  by  acoustic  equipment.  With  the  vehicle 
reprogrammed  as  a  follower,  the  captured  message  was  played 
back  into  the  water.  The  follower  vehicle  successfully  traced  a 
path  offset  from  the  simulated  leader  broadcast.  Future  tests 
will  involve  other  vehicles  currently  in  production  rather  than 
playback. 

VI.  CONCLUSION 

The  communications  module  successfully  fills  the  need  for 
multiple  modes  of  operation  in  an  AUV  test  platform.  The 
AUV  Control  Panel  allows  researchers  to  manually  control 
multiple  vehicles  into  start  position  and  recovery.  It  also 
interfaces  with  the  vehicles  to  put  them  into  mission  mode  or 
abort  them  out  of  mission  mode.  Through  the  web  pages, 
researchers  can  configure  the  vehicle,  zero  the  sensors,  upload 
missions,  and  download  data.  Lastly,  and  most  importantly, 
the  communications  module  provides  the  ability  to 
communicate  and  navigate  acoustically  while  the  vehicle 
operates  autonomously. 
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